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(54) Method and system for single sign-on user access to multiple web servers 

(57) Methods and systems for angle sign -on user 
access to multiple web servers are provided. A user is 
authenticated at a first web server (e.g., by user name 
and password). The first web server provides a web 
page to the user having a sen^lce selector (e.g., a 
hyperlink comprising the URL of a second web server 
offering the service indicated by the selector). When the 
user activates the sen/lce selector, the first web server 
constructs and transmits an encrypted authentication 
token (e.g., a cookie) from the first web server to a sec- 
ond web server via tine user client The first and second 
web servers share a sub-domain. The authentication 
token comprises an expiration time and is digitally 
signed by the first web server and is authenticated at 
the second web server. Upon authentication, the sec- 
ond web server allows the user to conduct a session at 
the second web server. 
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Description 

I. Cross Reference to Related Application 

5 [0001 ] This patent application claims priority to co-pending United States Provisional Patent Application Serial No. 
6(V155,853, entitled "Method and System for Single Sign-On User Access to a Federation o1 Web Servers," filed Sep- 
temt>er 24. 1 999, which is hereby Incorporated in full by reference. 

II. Reld of the Invention 

10 

[0002] The present invention relates generally to the field of electronic commence. More particular, embodiments of 
the present invention relate generally to a method and system for providing single sign-on user access to multiple web 
servers. 

IS III. Background of the Invention 

[0003] There are many situations In which an entity or group of entitles, such as a global financial institution with 
banking, brolcerage, and other aspects, wishes to combine the functional resources of different web application servers 
in order to aggregate functionality to the customers of the entity or group of entities. Such an entity or group of entities 
20 may wish to allow their customers access to such an aggregated functionality by signing on only once, by authenticating 
themselves once, and then being able to use different services which might be provided either by different servers of 
entities within the group of entitles, or by servers of the group of entities and, for example, by servers of third party enti- 
ties. 

[0004] In this context, tiie entity or group ot entities may wish to deliver to the customer, via a web browser, a set of 
25 services that are hosted by different web application servers. Such application servers may employ different platforms, 
such as a UNIX plattomi. an NT platfonn, or some other type of platfomri. The platfonn may have been constructed by 
different organizations within the group of entitles, or tiie platform may have been provided by third-party providers. In 
any event, an essential problem is how to allow the customer to sign on once and then to redirect the customer to these 
different servers without requiring the customer to sign on each and every time he or she goes accesses a different 
30 server. 

[0005] Conventional products attempting to address this problem are deficient, for example, both in temns of per- 
formance and cost. In some such products, it Is necessary to return to a centralized resource. Other such products do 
not support crossing organizational boundaries or Internet domain boundaries. What is needed is a methods and sys- 
tem for single sign-on user access to multiple web servers, such as a federation of web servers sharing sub-domains, 
35 that overconrte such disadvantages and that provide other advantages. 

IV. Summary of the Invention 

[0006] The present invention provides methods and systems for single sign-on user access to multiple web servers, 

40 such as a federation of web servers sharing sub-domains, are provided. In an embodiment, a user is authenticated at 
a first web server (e.g., by ussr name and password). The first web server provides a web page to the user having a 
service selector (e.g.. a hyperlink comprising the URL of a second web server offering the service indicated by the 
selector). Upon activation of tiie selector by the user, the first web server consti-ucts, digitally signs, and transmits an 
encrypted authentication token (e.g., a cookie) from the first web sender to a second web server via the user client. URL 

45 encoding Is employed to encrypt and sign the authentication token. The first and second web servers share a sub- 
domain. The auhentlcatton token comprises an expiration time. The authentication token Is examined and authenti- 
cated at the second web server and URL decoding Is employed. Upon authentication, and it the expiration time has not 
passed, the second web server allows the user to conduct a session at the second web server. 
[0007] In another embodiment, a method for single sign-on user access to a federation of web servers, such as a 

so first and second web server sharing a sub-domain, is provided. In an embodiment, the method comprises allowing a 
user at a computing device to access a first web server in tiie federation of web servers via a web browser of the com- 
puting device, authenticating the user with user-provided authentication information, including at least a user identifica- 
tion, by the first web server, and allowing the user to conduct a session a the first web server. During the session, the 
first web server carries out the functions of prompting the user for selection of a functionality offered via at least a sec- 

Bs ond web server, and receiving a selectton by the user of the functionality offered via the second web server. 

Upon receiving a selection, the first web server creates an authentication token for the user Including at least the user 
identrficatbn and with a pre-defined token expiry by the first web server, digitally signing (e.g., by public Icey encryption) 
the autiientication token by the first web server. An embodiment further comprises qualifying the domain attribute of the 
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authentication token with tlie shared sub-domain name by the first web server, sending the digitally signed authentica- 
tion token to the web browser of the computing devfce by the first web server, redirecting the web browser to the second 
web server by the first web server, and sending the authentication token to the second web server lay the web browser. 
The second web server decrypts the authentication token, confimis a match with the digital signature of the first web 
5 server, checks the pre-defined expiry of the authenticatkjn token by the second web server, and allows the user to con- 
duct a session with the second web server if within the pre-defined token expiry. 

[0008] In another embodiment, a method of single sign-on Tor multiple web servers, conprising receiving log-in 
data from a user in a first server, providing the userwith a service selector, receiving an indication that the user selected 
the service selector, constructing an authentfcalion token comprising profile data associated with the user, encrypting 
10 and signing the authentkiation token, redirecting the user to a second server, transmitting the authentication token to 
the user, receiving the authenticatksn token in the second server, verifying the authentication token in the second senrer, 
and allowing the user access to a service provided by the second server. In one such embodiment, the authentication 
token comprises a cookie and further comprises expiration time data. 

[0009] It is a feature and advantage of the present invention to provide a method and system for single sign^cn user 
IS access to a federation of web servers that altows users already authenticated on a web site, such as a financial institu- 
tion's web site, to have access, for example, to a service provider's web site without having to be re-authenticated via 
proviston of a valid name and password. 

[001 0] To achieve the stated and other features and advantages, an embodiment of the present invention provides 
a method and system which enables single sign-on access for a user to a federation of web servers that allows user 
20 authentication at an entity's web site server, selection of a service provider URL, and passage o1 an authentication 
token by the entity's web site server to a service provider's server that contains sufficient information to enable the serv- 
ice provider's server, for sxample, to recognize the user as a valid service provider user and to provide the user with 
customer specific information. 

[001 1 ] Additional objects, advantages and novel features of the invention will be set forth in part in the description 
25 whteh follows, and In part will become more apparent to those skilled in the art upon examination of the following, or 
may be learned by practice of the Invention. 

V. Brief Description of Figures 
JO [0012] 

FIG. 1 shows an embodiment of a system according to the present Invention. 

FIG. 2 shows a flow diagram describing a process according to the present invention carried out in the system 
shown In FIG. 1. 

35 FIG. 3 shows a visual depbtion of web pages associated with web servers of the system shown in FIG. 1 . . 

FIG. 4 shows a flow diagram deecribing an atternativa process according to the present invention earned out in the 
system shown in FIG. 1. 

VI. Detailed Description 

40 

[0013] FIG. 1 shows an embodiment of a system according to the present invention. A brokerage firm web server 
(BFWS) 30 Includes a brokerage fimi web site 32. The brokerage fimn web server 30 (and likewise the brokerage firni 
web site 32) is in communfcation with the Intemet 20. Likewise, a bank web server 40 includes a bank web site 42. The 
bank web server (BWS) 40 (and likewise the bank web site 42) is also in communication with the Internet 20. Acus- 

45 tomer 5 of both the brokerage firm and the bank is shown. The customer 5 has a user name and password to access 
both the brokerage firm web site 32 and the bank web site 42. The customer's personal computer 10 having a web 
browser such as Microsoft Internet Explorer or Netscape Navigator (a dl&nt) Is in communlcailon with the Intemet 20 
as well. The customer 5 uses the customer's personal computer and browser 1 0 to communicate with the web servers 
30, 40 via the Internet. Herein, the term customer is used In many instances to indicate the client 10 as used by the 

50 customer. In addition to network communication facilities and other aspects, the brokerage firm web server 30 and the 
bank server 40 comprise programming to carry out the functions described herein. 

[0014] FIG. 2 show© a flow diagram of steps carried out in the system shown in FIG. 1 . The customer 1 0 points the 
customer's browser to the brokerage fimn web site 32. The customer 10 logs into the brokerage timt web site 32 using 
the customer's correct user name (or user identification) and password for the brokerage firm web site 32, and is 
SB authentksated by the brokerage firm web server 30. Once the customer logs into the brokerage firm web site 32, the 
web site 32 presents the customer 10 wfth a welcome page from the web site 32. Once logged in, the customer 10 may 
examine the customer's brokerage account information, portfolio, investment infonnation, and the like. 
[001 5] FIG. 3 shows a graphical depictbn of the system shown in FIG. 1 , including the welcome page 1 00 from the 
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brokerage firm web site 30 pnovlclecl to the customer 1 0 once the customer logs in at the brokerage firm web site 30. 
The welcome page 100 shown In FIG. 3 includes a service selector in the form of a hyperlink shown as 'bill payment" 
1 02. The brokerage web site offers its customers the ability to pay bills. 

[00161 Refem'ng again to FIG. 2, the customer 1 0 requests bill payment 50 by clicking on the T)ill paymenf hyper- 
5 link 102. The brokerage firm v/eb server 30 itself does not handle the process of bill payment, but the server 30 is pro- 
grammed with the knowledge that the t>ank web server 40 handles such a process. The hyperlink 102 includes the URL 
of the bank web site 42. Upon detec^ng the request of blU payment, the brokerage firm server 30 builds an authentica- 
tion token 52. An authentication token comprises an object (or data) that can be passed between cooperating servers. 
A function of an embodiment of an authentication token is to convey the necessary infonnation from a primary (or first) 
10 senrerto a secondary (or second) serverto allow the secondary server to skip the sign-on process that would othenvise 
be necessary and required. Once a primary server establishes a session for a user, a cooperating secondary server 
that receives a valid authentication token from the primary server can establish a session without having the user sign 
on again. 

[0017] in the embodiment shown in FIG. 1, the brokerage firm v/eb server 30 builds an authentication token (or 

IS access token) comprising user Identifbation data (or profile data) and expiration time data (token expiry) 52. The profile 
data comprises user identification data comprising a customer k]ientification number that uniquely identifies the user to 
the secondary server. In the shown embodiment, the token also include a list o1 accounts of the customer. Expiration 
time data comprises data reflecting the time after which the authentication token is invalid. In the embodiment shown, 
the time is in Greenwich Mean Time (GMT). In other embodiments, the time may be in Universal Time. Expiration time 

20 may be set by the primary server at any desired time, though in most embodiments the expiration time is a relatively 
short time, e.g., three to twenty minutes, from the time at which the authentication token is created. In the embodiment 
shown, the expiration time is set at fifteen minutes from the time the authentication token is created. Notd that it is 
important for the servers exchanging such authentication tokens to maintain correct or synchronized clocks. The use of 
expiration time is used to create a single-use, perishable token. 

25 [0018] In the embodiment shown, the authentfcation token built comprises a cookie with profile data of the cus- 
tomer 5 and an expiration time of fifteen minutes from the creation time of the token. Authentication tokens may also 
comprise URL strings or other data that may be passed between servers. The profile data of the customer Includes a 
customer identification number for the customer 5. The brokerage firm web server 30 includes a data storage system 
(e.g., a hard disk drive) that has customer identification numbers associated with log-in usernames used by customer's 

30 of the brokerage firm web server 30. These numbers were agreed upon previously by the administrators of ttie servers 
30, 40. In the embodiment shown, a customer is associated with a customer dentification number. In the embodiment, 
when the customer requests bill payment 50, the server 30 retrieves, from the data storage system, the customer Iden- 
tification number for the customer 5. This customer identification number retrieved is used in the protiie data used to 
build the cookie 52. 

35 [0019] In another embodiment, various customer identification numbers are associated with various secondary 
servers. When.the customer requests a service provided at a secondary site (or to be transfen^ed to a secondary site), 
the primary server detects the request, determines the secondary site, and retrieves, from the data storage system, the 
customer identification number for the requesting customer that is associated with the secondary site to which the cus- 
tomer will be directed for bill payment services. 

40 [0020] Refening again to FIG. 2, the server 30 also selects the secondary sender recipient nanne 54. The server 30 
does so by examining the request made by the customer and detenmining the name / address of the appropriate sec- 
ondary server to handle the request. In the embodiment shown, the server 30 examines the "bill payment" request 
made by the customer. In the present embodiment the examination comprises detennnining the Uniform Resource 
Locator (URL) associated with the "bill payment" hyperlink. The web page file associated with the welcome page 100 

45 includes the URL associated with the "bill paymenr hyperlink, and the server 30 selects this URL. 

[0021] The sender 30 then signs and encrypts the cookie 56. A digital signature associated with the brokerage firm 
server 3D Is applied to the cookie 56 by the server 30. Preferably, the sender 30 comprises public key encryption soft- 
ware capable of encrypting, digitally signing, and authenticating electronic transactions across applications arid serv- 
ers. In the embodiment shown, the Entrust/PKI 5.0 software package, with its associated application programming 

so interface (API) library, available from Entrust Technologies, Inc., Piano, Texas, is used to sign tiie cookie using a pubPc 
key encryption system. In the embodiment shown, the cipher used is tiie Triple DES (Data Encryptton Standard) 
encryption algorithm system, the encrypted cookie uses privacy-enhanced mail (REM) headers, and signing uses the 
Secure Hash Algorithm (SHA-1 ) to create the message digest (or hash value) in signing. The Triple DES system is used 
to encrypt the authentication token (the cookie), and a REM header and SHA-1 digest is included. 

BS [0022] A digital signature associated with the server 30 (in the form of a signed-encrypted string) applied to the 
cookie allows a secondary server to verify that the authentication token was created by the brokerage firm server 30. 
Further, the signature allows a secondary serverto detect any modification or corruption of the authentcation token. 
The digital signature is applied and encrypted by the server 30. 
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[0023] In the embodiment shown, the cookie is created and kept on the browser 10 oT the user 5 using a header 
entry in the response page, and the header entry Is structured as follows: Set-cookie; name=value; explres=date-dme; 
domain=domainname; palh=path; secure. The path value comprises a specific directory, and the domainname value 
preferably Is a common sub-doma]n (discussed further below). In an embodiment, the authentkation token (the cookie) 
5 Is non-persistent and will not be written to disk on the customer client 1 0. In such an embodiment, an expires value is 
not necessary, and the cookie will be deleted by the receiving server immediately after receipt 
[0024] An ^(ampld of a string comprising cookie construction according to an embodiment of the present Invention 
Is as follows: 

10 VERl1EXPDTI19990505132540IICT\CUS7lAFIEXISniCIDI57600100056005023 4ll 
FClDI0HTAI2ilANMI001 0000001 IIRTNI099ilANAIMy wife's 
ChecklngllABI237600IIANMI0010000002IIRTN009IIANAIIVqy 

checkingllABI24556. The example Is In the follow! ngfcnmat Tagi TagValuel Tag2 TagValue2 Tag3 TagValueS .... 

IS [0025] It is noted that the specific tags and their tag values may vary according to implementation needs, such as 
destination server requirements. 

[0026] Tags tn the example shown, their value, and a description is shown in the following table: 


20 


Tag 

Tag Value 

Description 

VER 

1 

Version of cookie system being used (current version is 1) 

EXPDT 

Data /Time 

The ASCII GMT date and time that the authenticatton token ejfplres. Format: CCYYM- 
MDDHHMMSS. 

CT 

CUST FC 

Customer TVpe. CUST= regular customer FC=: Customer Representative, Used to 
activate view-only mode. 

AF 

NEW /EXIST 

New or existing customer indicator. 

CID 

Integer 

Customer Identification Number 

FCID 

Alphanumeric 

Identif Nation number for customer service representative. If the user is a regular cus- 
tomer, do not set FCID (i.e., set to 0). 

TA 

Integer 

Total Number of Accounts of customer 

ANM 

.Integer 

Account Number 

RTN 

Integer 

Routing transit Number - maps to prod-type-cd 

ANA 

Alphanumerb 

Account nick name 

AB 

Integer 

Account Balance In cents (i.e. $10.50=1050) 


[0027] In the embodiment shown, the order of tags Is not significant, except for ANM. M^/K, AB, which are consid- 
ered a tuple and are grouped together as shown above. Also, in the embodiment shown, the VER, EXPDT, and CT are 
45 required tags. Other tags that may be used In other embodiments Include the following: AG (agency or corporation 
name that employs the user), FNAM (first name of user), and LNAM (last name of user). 

[0028] ~me AF tag allows the bank server 40 to detemfilne If an "Activate User message should be sent to a tmns- 
action processing system (TPS). Preferably, if the brokerage firm web server 30 cannot determine whether a customer 
is new or already enrolled with GTPS, the server 30 sets the AF tag to NEW. In addition, the broker^© finn web server 
5a 30 shown assumes that all accounts are of the "Checking' type, and will set the product type code based on the RTN 
value determined. 

[0029] The brokerage firm server 30 then URL encodes (also called URLEncode) the constructed cookie 58. 
Essentially, in URL encoding the cookie, the broker firm web server converts the formatted string discussed above to a 
URL-encoded format In one embodiment, the URL encoding encodes the string using the URL escape syntax which 
ss oomprisee a three character string (%nn} specifying the hexadecimal code for a character. This syntax is used to hide 
characters that may be othenvise significant when used in a URL. The URL encoding 58 carried out by the brokerage 
finn web server 30 results in an encoded, signed, and encrypted string suitable for writing In a cookie, and such string 
is included in the cookie built by the server 30. 
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[0030] The brokerage firm web server 30 then sends a redirect command (or redirect page) with the URL encoded 
cookie (the authentication token) In a set-cookie header to the customer client 60. The redirect connmand Irxiludes the 
URL of the web site associated with 'biil payment* 42. The customer client 1 0 receives the redirect command and the 
URL encoded cookie constructed by the brokerage web server 30. 

5 [0031] The customer client 10 connects with the bank web site 42 via the Internet 20 and sends the cookie to the 
bank web sen/er 62. In the embodiment shown, the authentication token is transmitted In a Secure Sockets l.ayer (SSL) 
session. Further, In the embodiment shown, on receipt of the redirect command, the customer client 10 opens a second 
browser window, requests a download of the home page at the URL of the web site 42 (or the page designated In the 
URL), receives the page of the web site 42 from the bank web server 40, and displays the page in the window. An 

10 embodiment of such a window 1 1 0 and page is shown in FIG. 3. The coolde received by the customer client 10 from 
the brokerage fimn web server 30 is sent by the customer client 10 to the bank web server 40. 
[0032] The bank web server 40 receives the cookie from the customer client 10. The bank web server 40 decodes 
the encoded, signed, and encrypted string built into the cookie by the brokerage firm web server 30 into a signed, 
encrypted string 64. Such decoding employs URL Decoding (or URLDecode) methods in the embodiment shown. In 

IS the embodiment shown, URL Decoding b employed to convert the URL encoded string in the cookie to plain ASCII for 
examination by the bank web server 40. The bank web server 40 and the brokerage fImn web server 30 previously 
exchanged public-private key decryption information. 

[0033] Once the string Is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed, 
encrypted string that is now decoded) 6B. In the embodiment shown, software comprising public key encryption soft- 

20 ware capable of decrypting and authenticating electronic transactions across applications and servers is used by the 
bank web server 40 to do so. One example of such software is the Entmst/PKI 5.0 software package, with its associated 
application programming interface (API) library, available from Entrust Technologies, Inc., Piano, Texas. 
[Q034] The hank web server 40, using the software mentioned, determines whether the digital signature associated 
with the cookie verifies 68. If the signature does not verify, the bank web server 40 rejects the attempted sign-on and 

25 re-directs the customer client 10 to a web page on the brokerage fimi web server 30 Indicating an error and sign-on 
failure 70. resulting In a failed sign-on anempt 72. in another embodiment. If the signature does not verify, the bank web 
server 40 rejects the sign-on and sends a web page indicating an en'or and sign-on failure to the customer client 10. In 
an embodiment, if the signature does not verify, the bank web sender 40 also sends a message indicating such failure 
to the brolcerage firm web site 30, e.g.. an e-mail message. 

30 [0035] If the signature verifies, the bank web server 40 examines the Certificate Authority (OA) name associated 
with the cookie 74. The server 40 compares the CA name assodated with the cookie (i.e., the CA used with the CA 
name expected, as recorded in a registry file in the bank web server 40). If the CA name is not the one expected, the 
bank web server 40 re-directs the customer client 1 0 to an en^or page on the brokerage firm web server 70 arxJ the sign- 
on attempt fails 72, as described alx^ve. 

35 [0036] If the CA name is the CA name expected, the bank web server 30 next if the sender's name is con^ct 76. In 
doing so, the bank web server 30 determines whether the Common Name (CN) aeeociated with the cookie (i.e., the 
name being certified — the name used by the brokerage fimn web server 30) is an authorized name, in so detemiining. 
the bank web server 40 compares the CN associated with the cookie with a file containing authorized names In a data 
registry in the bank web server 40. If the CN is not the one expected, the bank web server 40 re-directs the customer 

40 client 10 to an enx>r page on the brokerage firni web sen/er 70 and the sign-on attempt falls 72, as described above. 
[0037] If the CN \s correct, i.e., the CIM is an authori2ed name, the bank web sen/er 40 extracts profile data from 
the cookie and begins a bill-payment session 78. In the embodiment shown, the server 40 parses the clear text data 
associated with the cookie (clear text refers to the infomnation that is not encrypted) 78. and examines the expiration 
time data in the cookie (not shown), if the expiration time has passed, the bank web server 40 re-directs the customer 

45 client 10 to an error page on the brokerage firni web server 70 and the sign-on attempt falls 72. as described above. 
The dear text data Includes profile data (e.g., customer Identification number). If the expiration time has not passed, the 
web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client the 
web page 11 0 of the bank web site 42 that is shown in FIG. 3, and the sign-on is successful 80. The customer client 10 
necehres the web page 100 and proceeds with the bill-payment session with the bank sen/er 40. In an embodiment, the 

50 authenticatk)n token (cookie) is then discarded or destroyed by the web server 40. 

[0036] In an attemative embodiment, the system reflects a service associated with a user's employee. One such 
embodiment is shown in FIG. 4. In the embodiment shown in FIG. 4. the process of this alternative embodiment gener- 
ally proceeds as that discussed above, with exceptions discussed below. The embodiment shown employs a primary 
server comprising a central web server having a central web site (not shown). The central web site comprises a web 

ss site at which the customer client 1 0 may request various servtees t>y clk^king a hyperlink. 

[0039] Refening to FIG. 4, the customer 6 signs on to the central web site 49, and the process 1 50, 1 52, 1 64, 1 66, 
158, 1 60, 1 62, 1 64, 1 66, 1 68, 170, 174, continues In a manner like that described above in relation to steps 50, 52, 54, 
56, 58, 60, 62, 64, 66, 68, 70, 74 shown FIG. 3, with the central web server serving as the primary server (the brokerage 
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web server served as the primary web server In the embodiment shown In FIG. 2) until the step shown as Item 77 
occurs. The primary server Includes the IbDowIng, additional tags in the cookie: AG (agency or corporation name that 
employs the user), FNAM (first name of user), and LfMAM (last name of user). The service provider refen^d to in FIG. 
4 comprises the secondary server, and in the embodiment shown comprises the bank web server 40. After the bank 

5 web server 40 detemines that the sendee's CA is correct, the web server 40 determines whether the customer / user's 
employer has signed up with the service provider associated v/ith the secondary server (the bank web server 40) 77. 
The bank web server 40 includes a database containing a Gst of employers who signed up with the servrce offered by 
the bank web server 40. The web server 40 compares the agency or corporation name in the AG tag with the list of 
employers. If the name in the AG tag is not on the list, the web server 40 re-directs the customer client 10 back to the 

w central web site for an error URL 70. 

[0040] If the name in the AG tag is on the Dst, the web server 40 continues the process by extracting profile data 
from the cookie and beginning a bill-payment session 78. After the bank web server 40 extracts profile data from the 
cookie and begins a bill-paynnent session 78, the server 40 examines a database (not shown) associated with the 
server 40 that includes data reflecting users who have previously s'gned up for or used the service provided by the 

IS server 40. If the user reflected by the cookie exists (i.e., has previously s^ned up for or used the service provided by 
tha server 40), the web server 40 retrieves a default web page previously selected as the user's defoult page and sends 
the default web page to the customer client 83, and the customer client 10 then may proceed wfth a bill-payment ses- 
sion 80. 

[0041 ] if the user reflected by the cookie does not exist (i.e., the database does not reflect that the user has previ- 
20 ously signed up for or used the service provided by the server 40), the web server 40 creates a user identification using 
the tag Information, including the AG, FNAM, and LNIAM tag information, and stores the user identification in a data- 
basa The server 40 then retrieves a pre-designated default web page and transmits the web page to tha customer cli- 
ent 83. The pre-designated default web page comprises a pre-designated web page for users associated with the 
agency / corporation indicated in the AG tag. The customer cOent 1 0 then may proceed with a bill-payment sessksn 60. 
25 [0042] In an embodiment multiple secondary servers are used in an embodiment of the present Invention. In still 
other embodiments, multiple primary servers are used. A group of one or more primary and one or mora secondary 
servers sharing log-In and other Infomiatlon as described herein may be referred to as a "federation" of servers. 
[0043] In the embodiments shown herein, a digital certificate generation software program is used to generate cer- 
tificates. An example of such software is the Entrust Solo Version 4.0 software package, available from Entrust Tech- 
no nologies, Inc., Piano, Texas. Preferably, when multiple secondeuy servers are employed in an embodiment of the 
present invention, the secondary servers will use the same profile (a file comprising information needed by the certifi- 
cate before the server can authenticate). Also, preferably, the CN name In the profile matches the generic host name of 
the secondary server. 

[0044] In embodiments, multiple primary servers are employed. The primary servers may use the same profile on 
35 all hosts or each host may use a separate profile. Like the secondary servers, certificates are employed in each primary 
server. 

[0045] In an embodiment servers sharing information between themselves that are maintained by different organ- 
izations use a shared domain in common In order to ease the sharing of information. In such an ennbDdlment a sub- 
domain is established or designated as the common sub-domain, the domain attribute of the authentication token (e.g., 
40 the shared cookie) is designated as the common sub-domain, and a "Forward IP (Internet Protocol) Pointer" entry is 
added in the DNS name servers of the cooperating organizations. 

[0046] For example, the primary server sets a cookie sub-domain of xxxx.yyyy.com (wherein yyyy.com comprises 
the domain name of the primary server). Using tail matching," cookies may be shared with any host whose domain tail 
is ■yyyy.com." When the server searches a cookie list on the user's computer for valid or useable cookies, the server 

45 compares the domain attributes of the cookie with the Internet domain name of the host. If there Is a tall match, then 
the cookie will go through path matching to see if It should be sent. Tall matching" means that domain attribute Is 
matched against the tall of the fully quailfled domain name of the host For example, a domain attribute of "xxxx.com" 
would match host names "yyyy.xxxx.com" as well as "zzzz.yyyy. xxxx.com. " For example, the primary server with which 
the user Interacts has a domain name of qqqq.yyyy.com, and the secondary server has a domain name of 

50 sss5.rn"r.yyyy.com, may share cookies in such an embodiment. In an embodiment, the IP pointer In the domain name 
server associated with the primary server either (1) maps the secondary server domain (ssss.rrrr.yyyy.com) to a pre- 
designated IP address associated with the secondary server; or (2) delegate the zone "mT" to a DNS name server 
associated with the secondary sender for resolution. 

[0047] As discussed above, certain embodiments of the present invention employ URL Encode and URL Decode. 
SB The following Is a code fragment written in Microsoft 0++ 6.0 showing an example of the implementatk>n of URL 
Encode by a server: 
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// URLEncode converts seme characters to %xx fonnat for sending 

//ma URL or -writing to a cookie 

// 

void URLEncode (BYTE* szDecoded, BYTE* szEncoded) 

{ 

BYTE* pszInPtr= szDecoded; 
BYTE* pszOutPtr = szEncoded; 
BYTE inch; 


while ((inch = *pszInPtrH-) != '\0') 
{ 

if( (inch < 32) || (inch > 127) || 
(inch = ='=') II (inch ==♦?') II 
Cinch = = *&') II (inch = = '+') || 
Cinch = = *%')|j (inch ==»-') || 
(inch «»*:') tl (inch =»';') || 
(inch»-V)) 

{ 

*pS20utPtrf+ = '%'; 
sprintf((char*)pszOutPtr, "%02x", inch); 
pszOutPtr+-2; 

} 

else 

*pS20iitPtr++ = inch; 

} 

*pszOutPtrf+='\0\;; 


The following code fragnent shows the implementafion of URL-Decode by as server: 
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// 

// URLDecode converts characters in the %xx format back to their ascii 

5 

values 

// 

void URLDecode (BYTE* szEncoded, BYTE* szDecoded) 
{ 

BYTE* ps2lnPtr= szEncoded; 
IS BYTE* pszOutPtr « szDecoded; 

int inch; 

^ while ((inch^*pszIntPtrf+) N*\0') 
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{ 

if(mch='%0 

♦pszOutPtrH- = (uiiHex{pszInPtr++) « 4) + 
unHex(*p52lnPtrH-); 

else 

*ps2£)utPtrt-t- = indi; 

} 

♦pszOutPtrH- = '\0'; 

} 

int unHex (BYTE hexChar) 
{ 

if ((hexChar»= '0') && (hexChar <= '9')) 

return hexChar - ' 0 ' ; 
if ((hexChar>= 'a') && (bexChar <= 'f )) 
retum hratChar - 'a' + 10; 
30 if ((hexChar >= *A') && (hexChar T*)) 

return heiChar - * A* + 10; 
return 0; 

} 
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15 


20 


25 


35 


[0049] Those of ordinary skill in the art will recognize that there are a variety of code fragments useful in carrying 
40 out such steps. Further, a variety of programming languages may be used. 

[0050] Various embodiments of the invention have been described in fulfillment of the various objects of the inven- 
tion. It should be recognized that these embodiments are merely illustrative of the principles of the present invention. 
Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the 
spirit and scope of the present invention. 

45 

Claims 

1. A method of single sign-on user access to multiple web servers, comprising: 


so authenticati ng a user at a first web server; 

tmnsmitting an encrypted authentication token from the first web sen/er to a second web server, wherein the 
authentication token comprises an expiration time and is digitally signed by the first web server; 
authenticating the authentication token at the second web server; and 
allowing the user to conduct a session at the second web server 

ss 

2. The method of claim 1 wherein the first web server and the second web server share a sub-domain. 

3. The niethod of claim 2 further connprising examining the expiration time o1 the authentication token at the second 
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web server and allowing the user to conduct a session at the second web server only If the expiration tjnne has not 
passed. 

4. The method of dainn 3 wherein the authentication token comprises a cookie. 

5 

5. The method of claim 4 wherein transmitting the encrypted authentteation token from the first web server to the sec- 
ond web server comprises transmitting the encrypted authentication token from the first web server to the user, and 
then from the user to the second web server. 

w 6. The method of claim 5 wherein authenticating the user at the first sender comprises receiving a user name and 
password 

7. The method of claim 6 wherein transmitting the encrypted authentication token from the first web server to a sec- 
ond web server comprises transmitting the authentication token from the first web server to a computer of the user; 

15 and transnrutting the authentbation token from the computer of the user to the second web server. 

8. The method of claim 7 wherein the first web server and the second web server comprise a federation of web serv- 
ers. 

20 9. The method of claim 8 wherein authenticating the authentication token at the second web server comprises exam- 
ining tiiecookia 

10. The method of claim 9 further comprising URL encoding tiie authenticatton token. 
25 1 1. Tiie method of claim 10 further comprising URL decoding the authentication token at the second web server. 

12. The method of claim 1 1 further comprising providing a web page to the user having a service selector. 

13. The method of claim 12 wherein the service selector comprises a hyperlink. 

30 

14. The method of claim 13 wherein the hyperlink comprises a UHL for the second web server. 

15. A method for single sign-on user access to a federation of web servers, comprising: 

35 allowing a user at b computing device to access a first web server in the federation of web servers via a web 

browser of the computing device; 

authenticating the user with user-provided authentication information, including at least a user identification, by 

the first web server; 

prompting the user for selection of a functtonafity offered via at least a second web server; 
40 receiving a selection by the user of the functionality offered via the second web server; 

creating an authentication token for the user including at least the user identification and with a pre-defined 

token expiry by \he first web sen^r; 

digitally signing the authenticatfon token by the first web server; 

qualifying the domain attribute of the authentication token with the shared sub-domain name by the first web 
45 server; 

sending the digitally signed authentication token to the web browser of the computing device by the first web 
server; 

redirecting the web browser to the second web server by the first web server; 
sending the authentication token to the second web server by the web browser; 
50 decrypting the authentication token by the second web server; 

checking the pre-defined expiry of the authentication token by the second web server; and 

allowing the user to conduct a sessbn with the second web server if within the pre-defined token expiry. 

16. The method of claim 16 further comprising allowing the user to conduct a session with the first web server 

ss 

17. The method of claim 16 wherein the second web server shares a sub-domain with the first web server. 

18. The method of daim 17 wherein digitally signing the authentbation token by thefirstweb server comprising digitally 
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signing the authentication token using public key encryption. 
19. The method of claim 18 further comprising confimiing a match with the digital signature. 
5 20. A nnethod of single 8ign-on for multiple web servers, comprising: 

receiving log-In data from a user In a first server: 

providing the user with a service selector; 

receiving an indication that the user selected the service seleaor; 
TO constructing an authentication token comprising profile data associated with the user; 

encrypting and signing the authentication token; 

redirecting the user to a second server; 

transmitting the authentication token to the user; 

receiving the authentication token in the second server; 
IS verifying the authentication token in the second server, and 

allowing the user access to a service provkJed by the second server. 

21 . The method of claim 20 wherein the authentication token further comprises expiration time data 
20 22- The method of claim 21 wherein the authentication token comprises a cookie. 

23. The method of claim 22 wherein the log-in data comprises a user name and password. 

24. The method of claim 23 wherein the service selector comprises a hyperlink. 

2S 

25. A system for single sign-on user access to multiple web servers, comprising: 

a means for authenticating a user at a first web server; 

a means for transmitting an encrypted authentication token from the first web server to a second web server, 
30 wherein the authentication token comprises an expiration time and is digitally signed by the first web server; 

a means for authenticating the authenticatbn token at the second web server; and 
a means for allowing the user to conduct a session at the second web server. 

26. The system of claim 25 wherein the first web server and the second web server share a sub-domain. 

35 

27. The system of claim 26 further comprising a means for examining the expiration time of the authentication token at 
the second web server. 

28. The system of claim 27 wherein the authentication token comprises a cookie. 

40 

29. The system of daim 28 wherein the means for transmitting the encrypted authentication token from the first web 
server to the second web server comprises means for transmitting the encrypted authentication token f mm the first 
web server to the user, and then fmm the user to the second web server. 

4? 30. The system of claim 29 wherein the means for authenticating the user at the first web server comprises means for 
receiving a user nanne and password. 

31. The system of claim 30 wherein the means for transmitting the encrypted auttientication token from the first web 
server to a second web sender comprises means tor transmitting the authentication token from the first web server 
50 to a computer of the user and means for transmftting the authentication token from the connputer of the user to the 
second web server. 

3Z The system of claim 31 wherein the first web server and the second web server comprise a federation of web serv- 
ers. 

55 

33. The system of daim 32 wherein the means for authentteating the authentication token at the second web server 
comprises means for examining the cookie. 
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34. The system of claim 33 further comprising a means for URL encoding the authentication token. 

35. The system of daim 34 further comprising a means for URL decoding the authentication token at the second web 
server. 

• 5 

36. The system of dalm 35 further comprising a means tor providing a web page to the user having a service selector. 

37. The system of claim 36 wherein the service selector comprises a hyperlink. 

10 38. The system of claim 37 wherein the hyperiink comprises a URL for the second web server. 

39. A system for single sign-on user access to a federation of web servers, comprising: 

a means for allowing a user at a computing device to access a first web server in the federation of web servers 
15 via a web browser of the comp utlng device; 

a means for authenticating the user with user-provided authentication information, indudlng at (east a user 
identification, by the first web server; 

a means for prompting the user for selection of a functionaflty offered via at least a second web server; 
a means for receiving a selection by the user of the functionality offered via the second web server; 
20 a means for creating an authentbatlon token for the user Including at least the user identification and with a 

pre-detined token expiry by the first web server; 

a means for digitally signing the authentication token by tha first web server: 

a means for qualifying the domain attribute of the authentication token with the shared sub-domain name by 
the first web server: 

25 a means for sending the digitally signed authenttoatlon token to the web browser of the computing device by 

the first web server; 

a means for redirecting the web browser to the second web server by the first web server; 
a means for sending the authentteatian token to the second web server by the web browser; 
a means for decrypting the authenticatfon token by the second web server; 
30 a means for checking the pre-defined expiry of the authentication token by the second web server; and 

a means for allowing the user to conduct a session with the second web server if within the pre-defined token 
expiry. 

40. The system of claim 39 further comprising a means for allowing the user to conduct a session with the first web 
35 server. 

41. The system of claim 40 wherein the second web server shares a sub-domain with the first web server. 

42. The system of daim 41 wherein the means for drgitally signing the authentrcation token lay the first web server com- 
40 prising means for digitally signing the authentication token using public key encryption. 

43. The system of claim 42 further comprising a means for confirming a mateh with the digital signature. 

44. A system of single sign-on for multiple web servers, comprising: 

45 

a means for receiving log-in data from a user in a first sen/er; 

a means for providing the user with a service selector; 

a means for receiving an indication that the user selected the service selector; 

a means for constructing an authentication token comprising profile data associated with the user; 
50 a means for encrypting and signing the authentication token; 

a means for redirecting the user to a second server; 

a means for transmitting the authentication token to the user; 

a means for receiving the authentication token in the second server; 

a means for verifying tiie authentrcation token in the second server; and 
ss a means for allowing the user access to a service provided by the second server. 

45. The system of claim 44 wherein the authentication token further comprises expiration time data. 
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46. The system of claim 45 wherein the authentication token comprises a coolcie. 

47. The system of claim 46 wherein the log-in data comprises a user name and password. 
5 48. The system of claim 47 wherein the service selector comprises a hyperlinlc. 
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